❓ I'm wondering if there could be use cases that depend on that value, for example:

• test suites asserting things like expect(request).to('api.clerk.dev')
• strict firewalls configured to only allow outgoing traffic to api.clerk.dev and not api.clerk.com

These seem unlikely to me, but just wanted to point out that this has some small chance of breaking someone.

strict firewalls configured to only allow outgoing traffic to api.clerk.dev and not api.clerk.com

@agis Could you check the firewall rules if we support the clerk.com for all of our workers services (eg img.clerk.com)? If so, I think we could proceed with this PR.

test suites asserting things like expect(request).to('api.clerk.dev')

Could you elaborate more on this? In the javascript repo, I believe that all the tests are updated to use clerk.com

I was referring to customers' test suites and WAF, not our own (our own WAF is fine, since clerk.com is already used by a handful of customers already). I was just trying to envision any cases where changing this constant's value would break customers.

Feel free to disregard my comment if you believe this is highly unlikely.

Based on the above comments i think we should introduce the change of clerk.dev -> clerk.com) as part of the next major version and add references in the migration guide and changelog about changing the clerk domains to avoid causing issues in customers depending the requests to our systems (eg mocking the requests).